This accepts only TIME(6). A TIME value of any other precision (TIME(3), current_time(3), a CAST(... AS TIME(0)) column) doesn't match by exact precision, so it gets implicitly coerced to TimestampType (the first collection member) — and TIME -> TIMESTAMP isn't a valid cast, so the query fails at analysis instead of formatting. Every other TIME-accepting expression (MinutesOfTime, HoursOfTime, TimeFromMicros) uses AnyTimeType, which accepts all precisions 0-6 directly.

Worth adding a regression test on a non-6 precision input — every current test and golden query uses a TIME'...' literal, which defaults to TIME(6), so this gap is untested today.

intercept[Exception] passes on any throwable and only exercises the interpreted eval, not codegen. The exception it catches is a raw java.time DateTimeException from LocalTime.format (the pattern's syntax is valid, so validatePatternString passes and the failure only surfaces at format time) — there's no Spark error class, so the PR description's "clear error" is overstated. Consider rejecting date-only patterns with a proper Spark error, then pin this test to that specific exception/message and cover the codegen path too.

timeMicros holds a nanosecond value (the comment says "stored as nanoseconds", and TimeType is encoded in nanos-since-midnight). Rename to timeNanos to avoid misleading the next reader.

Follow-up on the prior thread (now that the exception type is pinned). A date-only pattern like yyyy-MM-dd is syntactically valid, so validatePatternString() passes at construction and this format call throws a raw java.time.UnsupportedTemporalTypeException at runtime — there's no Spark error class, so the PR description's "rejected at runtime with a clear error" is still overstated, and the test pins it only on the interpreted .eval path.

Centralizing the TIME format in one helper that both nullSafeEval and doGenCode call maps it to a proper error and covers codegen for free:

def formatTime(tf: TimeFormatter, nanos: Long, pattern: String): UTF8String =
  try UTF8String.fromString(tf.format(nanos))
  catch { case e: DateTimeException =>
    throw QueryExecutionErrors.invalidPatternError("to_char", pattern, e) }

QueryExecutionErrors.invalidPatternError already exists (INVALID_PARAMETER_VALUE.PATTERN) — no new error class needed. Then swap the test's interpreted-only intercept[...] { expr.eval(InternalRow(...)) } for checkErrorInExpression[SparkRuntimeException](expr, "INVALID_PARAMETER_VALUE.PATTERN", ...), which runs interpreted and codegen. If a Spark error is out of scope here, the minimal alternative is to drop "clear error" from the description and use checkExceptionInExpression[DateTimeException] (which still covers codegen). Non-blocking — fine to defer.

Following up on my own earlier suggestion to reuse this helper — having now seen the rendered message, it's misleading for these functions. invalidPatternError hardcodes parameter -> toSQLId("regexp") (it was written for regexp functions), so this produces The value of parameter(s) ``regexp`` in ``to_char`` is invalid: '<pattern>' — but to_char/to_varchar/date_format have no regexp parameter. And funcName is the literal "to_char" here and at the two codegen sites, yet DateFormatClass also backs date_format and to_varchar, so those are misreported.

Minimal fix is to pass prettyName instead of the literal. Fully dropping the regexp parameter would need a datetime-specific message rather than the regexp-oriented helper — your call whether that's worth it here, but the message is what users will see.

errClass is never used — the error wrapping now lives inside formatTimeWithError, so this is leftover. Remove:

This helper is called from both nullSafeEval (interpreted) and doGenCode, not codegen only:

Following up on my own earlier verification of SimplifyDateTimeConversions — I cleared it in the last two rounds, but that was incomplete. Accepting TIME here newly activates case 1 of that rule (sql/catalyst/.../optimizer/expressions.scala:1208), which rewrites date_format(to_timestamp(date_format(X, p), p), p) → date_format(X, p). The rule keeps the inner date_format, and its child X (the _ in e @ DateFormatClass(_, pattern, timeZoneId)) is unconstrained — so with this change it can be TIME. My prior reasoning only checked the outer position (always TimestampType — correct), but the rewrite preserves the inner node.

The elimination is a no-op only when X is micro-aligned. For a sub-microsecond TIME(7/8/9) value with a sub-micro fractional pattern, the original truncates through the micros TimestampType intermediate while the rewrite keeps full nanos:

-- time_col : TIME(9) '12:13:14.123456789'
select date_format(to_timestamp(date_format(time_col, 'HH:mm:ss.SSSSSSSSS'),
                                'HH:mm:ss.SSSSSSSSS'), 'HH:mm:ss.SSSSSSSSS');
-- unoptimized: 12:13:14.123456000   (truncated through micros)
-- optimized:   12:13:14.123456789   (rule returns inner date_format(time_col, ...))

Reachable in default config (to_timestamp lowers to GetTimestamp(_, _, TimestampType, ...) after ReplaceExpressions; only spark.sql.timeType.enabled is needed). Minimal fix: guard case 1 to skip when the inner DateFormatClass's child is TimeType (case 2 is fine — its DateFormatClass always sits over a GetTimestamp/TimestampType child). Worth a regression test asserting optimized == unoptimized for a TIME(9) round-trip.